[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [suse-security] DMZ Setup is killing me!!
On Friday 02 July 2004 17:28, Mike Branda wrote:
> Running SuSE 9.0 Pro.
>
> O.K. I'm about to give up. I've been messing with the setup for
> SuSEfirewall2 which is apparently a niced up front end to IPTABLES. I'm
> trying to get a DMZ up so when I have to fix something on our renderfarm
> at 3 AM I can do it from home through ssh. currently the firewall works
> with 2 NICs dividing my local net from the big bad ugly WWW. it is
> functioning properly and dropping everything that it should. now on to
> the DMZ. I've read a ton of stuff on how to set up internal DMZ's
> through FW_FORWARD_MASQ="0/0,10.0.1.2,tcp,80" which looks like it
> Masquerades and uses an inside IP on a third NIC that's not a "real
> world" IP. I can't get that working in any way. Then there's the
> preferred method of having a second, ISP issued "real world" IP, on the
> DMZ and It again resides on the third NIC but there is no masquerading
> and it looks like and it uses FW_FORWARD="127.0.0.1,127.0.0.2,tcp,1".
There are two ways indeed, but you may have things confused.
The most difficult way is with reallife IPs from your ISP. Then you either
need to subnet or do tricks with proxy-arp or so. The thing with subnetting
is, it's very neat but your ISP must cooperate otherwise it's hell.
Example: Your ISP gives you two subnets, these are just made-up numbers.
22.22.22.8/29 (8 IP numbers) and 22.22.22.16/29 (again 8 IP numbers)
Now you set eth1 to 22.22.22.10 and let's assume that 22.22.22.9 is the ISP's
gateway. You set eth2 to 22.22.22.17 thereby becoming the gateway for the
DMZ. Now the ISP has to add a route to its own router that says that all
traffic to 22.22.22.16/29 must be routed TO 22.22.22.10 !
Then, all is good, i.e. you configure your firewall accordingly of course.
So let's examine scenario two, with non-reallife IP numbers.
Here you have 22.22.22.10 on eth1, 192.168.0.x/24 on eth0 and you choose
another net for the DMZ which MUST NOT be the same as on eth0 !
So, let's take 192.168.99.0/24 in this example. So eth2 becomes 192.168.99.1
From there on it's simple; you make a series of rules like you had,
FW_FORWARD_MASQ="0/0,192.168.99.4,tcp,80" if you have a webserver in the DMZ
with IP 192.168.99.4. Add other statements for other ports and/or other
servers to that same line, between those quotes, separated with space.
You mustn't forget to set the right gateway on your DMZ boxes; they must have
the IP you set to eth2 as their default gateway: 192.168.99.1.
You may also have to make special arrangements so that internal hosts can
connect to the DMZ IIRC, but I don't remember offhand. Just try it.
Oh and one other tip: never try if it works with FTP as that is the most
difficult protocol you can possibly choose. In fact, for getting FTP to
work, you may need to do rather more than you've bargained for, depending on
whether it's active or passive FTP, whether it's coming from internal,
external or comes from the DMZ itself. Consider yourself warned.
Ftp is a real bitch, and it should've been shot ages ago... really
Good luck,
Maarten
> The forelisted FW lines are straight out of the EXAMPLE included with
> SuSE so they really don't apply to my network directly. let me sum up
> what I have and maybe somebody can point me in the right direction.
>
> Firewall box:
>
> FW_DEV_INT="eth0"
> FW_DEV_EXT="eth1"
> FW_DEV_DMZ="eth2"
>
>
> the external has my first ISP assigned IP. the internal is the generic
> 192.168.2.0 network. what I'm not sure of is what IP needs to be on
> eth2 real or masq'd and any custom routing. I've tried everything I can
> think of. including a same and different internal IP, another of my real
> world IP's you name it. routes?? and maybe howto??
>
> DMZ box
>
> eth0 tried internal IP, real world IP......all in pairs because AFAIK if
> the subnet isn't the same and the networks are different they wont ping.
> the only life out there I get is when I use and internal IP like
> 192.168.0.1 on eth2 for the firewall and 192.168.0.2 on the DMZ. then I
> can ping from firewall to DMZ and vice versa. but when I go from there
> to try and use the FW_FORWARD_MASQ, I still can't get in from home on
> the outside. the only reason I'm pursuing the masq setup is I can't get
> anything else to ping. I'd prefer to do it the other way but it's not
> getting anywhere. so here's the snip from the masq field:
>
> # Which services accessed from the internet should be allowed to
> masqueraded
> # servers (on the internal network or dmz)?
> # REQUIRES: FW_ROUTE
> #
> # With this option you may allow access to e.g. your mailserver. The
> # machines must be in a masqueraded segment and may not have public IP
> addesses!
> # Hint: if FW_DEV_MASQ is set to the external interface you have to set
> # FW_FORWARD from internal to DMZ for the service as well to allow
> access
> # from internal!
> #
> # Please note that this should *not* be used for security reasons! You
> are
> # opening a hole to your precious internal network. If e.g. the
> webserver there
> # is compromised - your full internal network is compromised!!
> #
> # Choice: leave empty (good choice!) or use the following explained
> syntax
> # of forward masquerade rules, seperated each by a space.
> # A forward masquerade rule consists of 1) source IP/net, 2) destination
> IP
> # (dmz/intern), 3) a protocol (tcp/udp only!) and 4) destination port,
> # seperated by a comma (","), e.g. "4.0.0.0/8,1.1.1.1,tcp,80"
> # Optional is a port after the destination port, to redirect the request
> to
> # a different destination port on the destination IP, e.g.
> # "4.0.0.0/8,1.1.1.1,tcp,80,81"
> #
> FW_FORWARD_MASQ="0/0,10.0.1.2,tcp,80" # Beware to use this!
>
>
> Any help would be appreciated. I'm feeling beat up by what should be so
> simple... :^(
>
> Mike
--
Yes of course I'm sure it's the red cable. I guarante[^%!/+)F#0c|'NO CARRIER
--
Check the headers for your unsubscription address
For additional commands, e-mail: suse-security-help@xxxxxxxx
Security-related bug reports go to security@xxxxxxx, not here