On 12/03/13 03:38, Tom Eastep wrote: > On 3/11/13 5:05 PM, "[email protected]" <[email protected]> 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/shorewall-users Does 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.
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
