darx@sent.com
2013-Mar-11 07:20 UTC
Need some help with a new SNAT/DNAT/NAT + DMZ + Xen Host/Guest config.
Hi.
I''m migrating to shorewall(6) mgmt of my various firewalls.
Simple configs have been easy with the great docs.
I''ve got a slightly more convoluted config, and have gotten
''lost'' in
config''ing a SNAT/DNAT/NAT + DMZ + Xen Host/Guest set up with Static
IP/29. Having some challenges wrapping my head around the
''best''
Shorewall approach :-/
Here''s a 1st shot at explaining what I have and what I need help with:
I''ve a static x.x.x.17/29 from my ISP.
My setup is:
ADSL modem, bridge mode
|
|
|
Box 1 |
eth0
Ext x.x.x.17/24, Gateway x.x.x.1
firewall
split DNS -- listen on x.x.x.18 & 192.168.1.100
Int 192.168.1.100/24
eth1
|
|
|
port 1
GBit Switch
port 2--------------------------------port 3--------
port(s) 4-...
| | |
Box2 | |
Box(es) 4 ...
eth0 |
eth0
mail server, listen on 192.168.1.125 |
@ ip == 192.168.1.4 ...
|
Box 3
eth0
xen server
Dom0,
192.168.1.200
DomU #1
10.10.1.201,
www listen
on 80 &
443
I need to ensure the following source/destination IP & port mapping for
inbound & outbound traffic:
Svr MAIL:
net --> x.x.x.19:{25,143,587} -->
192.168.1.100:{25,143,587}
192.168.1.100:{25,143,587} --> x.x.x.19:{25,143,587} -->
net
Svr DNS:
net --> x.x.x.18:53 --> 192.168.1.100:53
192.168.1.100:53 --> x.x.x.18:53 --> net
Svr WWW:
net --> x.x.x.20:{80,443} --> 10.10.1.201:{80,443}
10.10.1.201:{80,443} --> x.x.x.20:{80,443} --> net
and
enable ping access from net to Svr{MAIL,DNS,WWW}
enable ssh access from @ LAN Desktops 192.168.1.4 ... to
Svr{MAIL,DNS,WWW}
default/fallback outbound src ip map for all lan-originated
traffic is x.x.x.17
Is getting this all working ''simply'' an issue of NAT? no proxy
arp
required?
Iiuc, I wouldn''t use a Shorewall DMZ zone for this config, would I?
With shorewall NAT setup, will the inbound/outbound routing -- between
the LAN segmentes AND enabling per-external-IP source mapping -- be
automatically generated?
Thanks,
DarylX
------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in
the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
Matt Joyce
2013-Mar-12 00:10 UTC
Re: Need some help with a new SNAT/DNAT/NAT + DMZ + Xen Host/Guest config.
Before I go ahead and start going through your questions on this one I want to clarify is there some particular reason why you are intentionally keeping the the real IP addresses outside of the LAN, you are aware I presume that you can set up your interfaces on the servers with both a real IP address and an internal one if you wanted to, that is how I used to work it when I had my /29 set up. On 11/03/13 07:20, darx@sent.com wrote:> Hi. > > I''m migrating to shorewall(6) mgmt of my various firewalls. > > Simple configs have been easy with the great docs. > > I''ve got a slightly more convoluted config, and have gotten ''lost'' in > config''ing a SNAT/DNAT/NAT + DMZ + Xen Host/Guest set up with Static > IP/29. Having some challenges wrapping my head around the ''best'' > Shorewall approach :-/ > > Here''s a 1st shot at explaining what I have and what I need help with: > > I''ve a static x.x.x.17/29 from my ISP. > > My setup is: > > ADSL modem, bridge mode > | > | > | > Box 1 | > eth0 > Ext x.x.x.17/24, Gateway x.x.x.1 > firewall > split DNS -- listen on x.x.x.18 & 192.168.1.100 > Int 192.168.1.100/24 > eth1 > | > | > | > port 1 > GBit Switch > port 2--------------------------------port 3-------- > port(s) 4-... > | | | > Box2 | | > Box(es) 4 ... > eth0 | > eth0 > mail server, listen on 192.168.1.125 | > @ ip == 192.168.1.4 ... > | > Box 3 > eth0 > xen server > Dom0, > 192.168.1.200 > DomU #1 > 10.10.1.201, > www listen > on 80 & > 443 > > I need to ensure the following source/destination IP & port mapping for > inbound & outbound traffic: > > Svr MAIL: > net --> x.x.x.19:{25,143,587} --> > 192.168.1.100:{25,143,587} > 192.168.1.100:{25,143,587} --> x.x.x.19:{25,143,587} --> > net > > Svr DNS: > net --> x.x.x.18:53 --> 192.168.1.100:53 > 192.168.1.100:53 --> x.x.x.18:53 --> net > > Svr WWW: > net --> x.x.x.20:{80,443} --> 10.10.1.201:{80,443} > 10.10.1.201:{80,443} --> x.x.x.20:{80,443} --> net > > > and > enable ping access from net to Svr{MAIL,DNS,WWW} > enable ssh access from @ LAN Desktops 192.168.1.4 ... to > Svr{MAIL,DNS,WWW} > default/fallback outbound src ip map for all lan-originated > traffic is x.x.x.17 > > Is getting this all working ''simply'' an issue of NAT? no proxy arp > required? > > Iiuc, I wouldn''t use a Shorewall DMZ zone for this config, would I? > > With shorewall NAT setup, will the inbound/outbound routing -- between > the LAN segmentes AND enabling per-external-IP source mapping -- be > automatically generated? > > Thanks, > > DarylX > > ------------------------------------------------------------------------------ > Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester > Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the > endpoint security space. For insight on selecting the right partner to > tackle endpoint security challenges, access the full report. > http://p.sf.net/sfu/symantec-dev2dev > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev
darx@sent.com
2013-Mar-12 00:25 UTC
Re: Need some help with a new SNAT/DNAT/NAT + DMZ + Xen Host/Guest config.
Hi On Mon, Mar 11, 2013, at 05:10 PM, Matt Joyce wrote:> Before I go ahead and start going through your questions on this one I > want to clarify is there some particular reason why you are > intentionally keeping the the real IP addresses outside of the LAN, you > are aware I presume that you can set up your interfaces on the servers > with both a real IP address and an internal one if you wanted to, that > is how I used to work it when I had my /29 set up.Two reasons: (1) it''s similar to what''s been already deployed, and i''m migrating (2) the number of servers that I need to expose externally exceeds the # of IPs I''m allocated. What I''ve provided here is simplified to demonstrate: (a) one listening daemon on the firewall box (b) one listening daemon on a dedicated box in the lan (c) one listening daemon on a Xen guest These three cases cover all my servers ... The docs @ shorewall are so extensive, I keep chasing down individual-topic rabbit-holes filled with myriad options. I end up having a hard time wrapping my head around the simplest approach for "my environment". The IPv6 side of the equation is a different story, of course. Cheers, -darx ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev
darx@sent.com
2013-Mar-12 01:05 UTC
Re: Need some help with a new SNAT/DNAT/NAT + DMZ + Xen Host/Guest config.
Hi On Mon, Mar 11, 2013, at 06:32 PM, Tom Eastep wrote:> I would also like to recommend separate LANs for the servers and other > client systems. I dislike not having a firewall between the two, because > your internet-facing servers are the most likely targets of hackers.Logically separate LANs are certainly an option. As for physically separated, for now, we''re interface limited. So, iiuc, something like: -------------------------------- Firewall Box: ext intfc: eth0, x.x.x.17/24, Gateway x.x.x.1 DNS daemon, listen @ 192.168.0.100/24 int intfc: eth1, 172.16.1.100/24 Mail Server Box: intfc: eth0, 192.168.1.25/24 Xen Server Box: Dom0 intfc: eth0, 172.16.1.200/24 br0 -> DomU1 intfc: eth0, 10.0.1.200/24 DomU2 intfc: eth0, 10.0.2.200/24 Desktops intfc: eth0, 172.16.1.XX -------------------------------- would provide (some of) that separation ? that, i presume, adds a bunch of shorewall config complexity for rules and routes. also, fwiw, the ''switch'' between the firewall box and the rest of the physical LAN *is* a managed switch, vlan capable. QoS -- generally and VoIP-specific -- is also "in there" to deal with, with tagging & allocation across the LAN(s). for now I''m treating it as a dumb switch until I get further along. darx ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev
Tom Eastep
2013-Mar-12 01:32 UTC
Re: Need some help with a new SNAT/DNAT/NAT + DMZ + Xen Host/Guest config.
On 3/11/13 4:10 PM, "Matt Joyce" <mjoyce@mttjocy.co.uk> wrote:>Before I go ahead and start going through your questions on this one I >want to clarify is there some particular reason why you are >intentionally keeping the the real IP addresses outside of the LAN, you >are aware I presume that you can set up your interfaces on the servers >with both a real IP address and an internal one if you wanted to, that >is how I used to work it when I had my /29 set up.I would also like to recommend separate LANs for the servers and other client systems. I dislike not having a firewall between the two, because your internet-facing servers are the most likely targets of hackers. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev
darx@sent.com
2013-Mar-12 02:49 UTC
Re: Need some help with a new SNAT/DNAT/NAT + DMZ + Xen Host/Guest config.
Hi, On Mon, Mar 11, 2013, at 08:38 PM, Tom Eastep wrote:> On 3/11/13 5:05 PM, "darx@sent.com" <darx@sent.com> wrote: > Some (but not much). Broadcast traffic on the LAN is visible to all > hosts, so each of the subnets is quickly exposed to the other.Iiuc (?), isolating broadcast traffic can be addressed by pulling the managed switch w/ vlans into the mix. But, I''ve -- again -- gotten too far down the complexity path. For now, I''m still trying to figure out ''just'' that which I addressed in the OP. -darx ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev
Tom Eastep
2013-Mar-12 03:38 UTC
Re: Need some help with a new SNAT/DNAT/NAT + DMZ + Xen Host/Guest config.
On 3/11/13 5:05 PM, "darx@sent.com" <darx@sent.com> wrote:>Hi > >On Mon, Mar 11, 2013, at 06:32 PM, Tom Eastep wrote: >> I would also like to recommend separate LANs for the servers and other >> client systems. I dislike not having a firewall between the two, because >> your internet-facing servers are the most likely targets of hackers. > >Logically separate LANs are certainly an option. As for physically >separated, for now, we''re interface limited. > >So, iiuc, something like: > >-------------------------------- >Firewall Box: > ext intfc: eth0, x.x.x.17/24, Gateway x.x.x.1 > DNS daemon, listen @ 192.168.0.100/24 > int intfc: eth1, 172.16.1.100/24 > >Mail Server Box: > intfc: eth0, 192.168.1.25/24 > >Xen Server Box: > Dom0 > intfc: eth0, 172.16.1.200/24 > br0 -> > DomU1 > intfc: eth0, 10.0.1.200/24 > DomU2 > intfc: eth0, 10.0.2.200/24 > >Desktops > intfc: eth0, 172.16.1.XX >-------------------------------- > >would provide (some of) that separation ?Some (but not much). Broadcast traffic on the LAN is visible to all hosts, so each of the subnets is quickly exposed to the other. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev
Matt Joyce
2013-Mar-12 10:19 UTC
Re: Need some help with a new SNAT/DNAT/NAT + DMZ + Xen Host/Guest config.
On 12/03/13 03:38, Tom Eastep wrote:> On 3/11/13 5:05 PM, "darx@sent.com" <darx@sent.com> wrote: > >> Hi >> >> On Mon, Mar 11, 2013, at 06:32 PM, Tom Eastep wrote: >>> I would also like to recommend separate LANs for the servers and other >>> client systems. I dislike not having a firewall between the two, because >>> your internet-facing servers are the most likely targets of hackers. >> Logically separate LANs are certainly an option. As for physically >> separated, for now, we''re interface limited. >> >> So, iiuc, something like: >> >> -------------------------------- >> Firewall Box: >> ext intfc: eth0, x.x.x.17/24, Gateway x.x.x.1 >> DNS daemon, listen @ 192.168.0.100/24 >> int intfc: eth1, 172.16.1.100/24 >> >> Mail Server Box: >> intfc: eth0, 192.168.1.25/24 >> >> Xen Server Box: >> Dom0 >> intfc: eth0, 172.16.1.200/24 >> br0 -> >> DomU1 >> intfc: eth0, 10.0.1.200/24 >> DomU2 >> intfc: eth0, 10.0.2.200/24 >> >> Desktops >> intfc: eth0, 172.16.1.XX >> -------------------------------- >> >> would provide (some of) that separation ? > Some (but not much). Broadcast traffic on the LAN is visible to all hosts, > so each of the subnets is quickly exposed to the other. > > -Tom > You do not need a parachute to skydive. You only need a parachute to > skydive twice. > > > > > > ------------------------------------------------------------------------------ > Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester > Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the > endpoint security space. For insight on selecting the right partner to > tackle endpoint security challenges, access the full report. > http://p.sf.net/sfu/symantec-dev2dev > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-usersDoes that apply equally if using properly configured vlan tagging etc? Of course I''m aware that even with placing some local rules to enforce it a fully root compromised box would allow them to enable, disable, change or otherwise play games with your boxes vlan setup as much as they wanted to. I''m also tend to think when it comes down to that, firstly it would act to limit the potential attack vectors from the simply logically separated idea where probably the most basic forms of attack on a vulnerable PHP/Rails/CGI web application could I suspect be sufficient to enable manipulation of services accepting broadcast traffic even while the http daemon and the rest of the system remain secure and with no more privileges than they were supposed to have. If manipulating such as vlan tags and/or disabling iptables/selinux or similar policy enforcement regulating outgoing traffic is required I''d have thought some form of system wide compromise with privilege escalation would be a minimum (For the sake of argument assuming that all internet facing servers have fully dropped root and not merely switched euid or similar uid=0). If I''m right on that part I would personally be inclined to consider that to be reasonably acceptable especially on a temporary basis, mainly because to my mind once a hostile agent has successfully managed to gain root on a local system you have bigger problems than broadcast disruption to worry about, especially if the compromised machine is one that is trusted by internal clients to serve content or handle sensitive data etc which usually be pretty much all of them in my experience often to the point of seeming irrational. Actually it''s a little bit off on a tangent but saying that reminds me of setup I came across earlier this year which just seems like a fitting example how never to set up a firewall. It''s interesting in a way because it''s mostly well set up everything on it''s own interfaces and independent only for a badly thought out policy rule to turn it into a disaster waiting to happen. It does go off on a tangent so if it doesn''t interest you it''s safe to just skip reading from this paragraph onwards. Basic topology: Internet connectivity through a pair of 155Mbps fibre connections to two different providers (a stones through from LINX is a lucky place to have an office) each terminating on one of two physical gateways with a gigabit ethernet crosslink between them for load balancing and fallover. Filtered into an internal network of three basic zones a group of internal servers predominantly an oracle DB cluster but also the usual like In/Outbound Mail, Directory services. Second subnet of servers consists of a group of HTTP servers being used to serve both the the external website and the intranet site, 2 MX relays which handle mail actually entering and leaving and redundant set of proxy servers that handle outbound traffic. The final zone has ~650 employee workstations sub-netted to departments but the interdepartmental routers don''t do any filtering two or three iptables rules that look like someone''s band-aid job that nobody remembers why they were even added. Topology all looks great until you look at the actual filtering rules it is set up such that only the second group of servers communicates with external hosts, filtering is well set up between the two sets of servers also, internal servers can send/receive from the proxy/MX/DNS servers only what they actually need to perform their function. Then you have the policy from the main LAN to the border server group and I can only presume whoever set this up fell asleep before they got to this stage apart from the rules to prevent direct Internet-LAN and LAN-Internet traffic it''s an ACCEPT policy both ways, going to all that effort to keep it secured from direct contact with the Internet only to present 38 single points of failure for the entire house of cards directly to the Internet with a vast array of dameons to play with (Apache2 w PHP and Rails and 6 different web applications publicly visible ones anyway, Bind, Squid, Socks proxy Dante I think, Postfix, Several stupidly placed back-end MySQL servers, Courier IMAP providing email access for mobile employees, Rsyncd, some others but forget which packages an ftpd). And not sure how I ended up off on that tangent just came to me there and seemed like a really great example for anyone how *NOT* to setup a firewall. Takes far too much work getting them all set up right to offer every script kiddie who gets bored a menu to pick from to walk right on around it, once I saw the setup and figured out which server got compromised only surprise to me was how on earth it hadn''t happened earlier. ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev
Tom Eastep
2013-Mar-12 14:39 UTC
Re: Need some help with a new SNAT/DNAT/NAT + DMZ + Xen Host/Guest config.
On 03/12/2013 03:19 AM, Matt Joyce wrote:> Does that apply equally if using properly configured vlan tagging etc?No.> Of course I''m aware that even with placing some local rules to enforce > it a fully root compromised box would allow them to enable, disable, > change or otherwise play games with your boxes vlan setup as much as > they wanted to. I''m also tend to think when it comes down to that, > firstly it would act to limit the potential attack vectors from the > simply logically separated idea where probably the most basic forms of > attack on a vulnerable PHP/Rails/CGI web application could I suspect be > sufficient to enable manipulation of services accepting broadcast > traffic even while the http daemon and the rest of the system remain > secure and with no more privileges than they were supposed to have. If > manipulating such as vlan tags and/or disabling iptables/selinux or > similar policy enforcement regulating outgoing traffic is required I''d > have thought some form of system wide compromise with privilege > escalation would be a minimum (For the sake of argument assuming that > all internet facing servers have fully dropped root and not merely > switched euid or similar uid=0). > > If I''m right on that part I would personally be inclined to consider > that to be reasonably acceptable especially on a temporary basis, mainly > because to my mind once a hostile agent has successfully managed to gain > root on a local system you have bigger problems than broadcast > disruption to worry about, especially if the compromised machine is one > that is trusted by internal clients to serve content or handle sensitive > data etc which usually be pretty much all of them in my experience often > to the point of seeming irrational.My point about broadcast is simply that it allows for easy discovery of the other IP subnet(s) sharing the LAN (assuming no vlan). This requires that the box be root-compromised, of course. Adding an IP address in the other subnet would then enable direct communication with the hosts in that subnet without any intervening firewall to worry about. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev