RE: [fw-wiz] Defense in Depth to the Desktop

From: Ben Nagy (
Date: 12/06/04

  • Next message: Dave Piscitello: "Re: [fw-wiz] Re: Spyware mumbo jumbo and bigger woes"
    To: "'Chris Pugrud'" <>, <>
    Date: Mon, 6 Dec 2004 10:38:29 +0100

    Hi Chris,

    I like it. I remember floating the same idea about four or five year ago,
    using non-encrypted IPSec to isolate the clients instead of VLANs. (not that
    it was new even then ;)

    Adding the IPSec to the mix has some fringe benefits in terms of eliminating
    rogue clients, and being able to make user sensitive rule changes. It also
    has some massive downsides for non-homogenous networks, but if you have a
    W2K or later client pool I would assert that it's actually nicer.

    You might also want to consider (ick) MS ISA Server for networks that have a
    predominantly MS client pool (most). That will give you much better state
    tracking for the tricksy SMB/CIFS/NetBIOS stuff, as well as user sensitive
    rules as a side benefit. There are not many Stateful Packet Filters that can
    do 'proper' state for ms-rpc and other nasty windows stuff which uses a lot
    of UDP. Many (most?) just open up the UDP port for return traffic for a time
    window. Well, at least they used to.

    One small flaw in your model is the "lurker worm" that sits on a server and
    waits for a client to connect on the appropriate service. Imagine, for
    example, a 0day LSASS worm - if the server is infected then the client pool
    will be rapidly infected as well, because as soon as they talk to a domain
    controller (in windowsland) the DC will helpfully send them a copy of the
    worm for free. This doesn't invalidate the model, but it's an important
    clarification of limitations. This is kind of similar to download.ject and
    the recent IFRAME attacks which used an infected adserver. (so it's not an
    alien model to h4x0rs).

    I also have some observations - you're using a LOT of vlans. How are you
    going to manage that for large client pools? I think that tagging only gives
    you 4096 IDs, right? Besides, tagging leaves you open for "side to side"
    client infections for clients that are new / misconfigured / not supposed to
    be there. I suppose you would want to use switchport based VLANs, but that
    sounds like switch config hell.

    Overall, I kinda like the model. I think your big vulnerabilities are the
    configuration management and the VLANs (also insert "VLANs were not made to
    enforce security barriers" rant here), and also the technical details of the
    statefulness of your firewall with respect to lurker worms.



    > -----Original Message-----
    > From:
    > [] On Behalf
    > Of Chris Pugrud
    > Sent: Thursday, December 02, 2004 8:24 PM
    > To:
    > Subject: [fw-wiz] Defense in Depth to the Desktop
    > Defense in Depth to the Desktop
    > the Strong Internal Network Defense model
    > Most organizations have expended large amounts of money and
    > resources in
    > strengthening their perimeter defenses, primarily through
    > firewalls and similar
    > network hardware mechanisms. Additionally, most
    > organizations rely only on
    > operating system security controls for the internal networks,
    > not applying
    > strong internal security controls. The lack of strong
    > internal security
    > controls is highlighted when the internal network and systems suffer
    > catastrophic failure when attackers, malware, and, most
    > destructively, worm
    > viruses make their way into the network inside the defensive
    > perimeter. This
    > is the classic "eggshell" weakness of network security, hard
    > and crunchy on the
    > outside, soft and chewy on the inside. The Strong Internal
    > Network Defense
    > (SIND) model attempts to address this key vulnerability
    > through the application
    > of hard internal defenses through network hardware.
    > Overview
    > Consider the following example of a simplified network. The
    > network is divided
    > into two subnets; one subnet contains all of the client
    > systems, while the
    > second subnet contains all of the servers. The client subnet
    > and the server
    > subnet are separated by a session based, stateful, packet
    > filtering firewall.
    > The firewall is unidirectional; it only permits traffic that
    > is initiated from
    > a client to a server. Servers are allowed to reply to
    > clients, but they can
    > not initiate communication, TCP or UDP, to a client.
    > Surprisingly, this example does not break Microsoft or most
    > application [*1]
    > protocols. The result is counterintuitive, but analysis and
    > testing support
    > this assertion.
    > In addition to the firewall, the client systems are fully
    > isolated from each
    > other by layer 2 controls (private vlans). The servers may
    > be similarly
    > isolated, but doing so is minimally effective and damaging to
    > server to server
    > communications.
    > Consider the introduction of a zero day worm virus [*2] into
    > such a network by
    > an infected client. The client can attack all of the
    > servers, and all of the
    > servers may become infected. The infected client can not
    > attack any of the
    > other clients because of the layer 2 isolation. The infected
    > servers can not
    > attack any of the clients because of the firewall. The end
    > result is that one
    > client and the servers, a small subset of the organization,
    > are infected. This
    > is much less devastating, and much easier to clean up, than
    > if the entire
    > network was infected.
    > [*1] MAPI, the protocol used by MS Exchange clients
    > (outlook) and the server
    > has a quirk, acknowledged by Microsoft, affecting new mail
    > notification.
    > Despite the presence of a perfectly capable TCP connection
    > from client to
    > server, the server sends a small new mail notification
    > message to the client
    > from a random high port, UDP, to a dynamic high port on the
    > client. Microsoft
    > has acknowledged the issue, as highlighted by using clients
    > through a NAT
    > gateway, but does not give an indication that they care to fix it.
    > [*2] The infamous zero day worm virus is invoked as a worse
    > case analysis
    > because it invalidates anti-virus and patch defense
    > mechanisms. Since worms
    > are increasingly targeting necessary network ports, personal
    > firewalls are also
    > equally invalidated as a defense mechanism. Marcus can
    > gleefully dance on
    > their graves.
    > Analysis
    > The primary design of the model is to focus security
    > resources on the servers.
    > No organization can reasonably maintain strict control over
    > client systems, but
    > they do have absolute control over making sure that servers
    > are currently
    > patched and running the latest AV signatures. The need to
    > keep client systems
    > on the patch and AV treadmill is greatly diminished. Client
    > systems can not
    > directly affect the security of other clients systems, they
    > can only attempt to
    > harm the servers and themselves.
    > Application protocols that are broken are peer to peer
    > systems and any kind of
    > desktop file sharing. This is strongly viewed as a good thing in most
    > organizations. If I was an attacker going after juicy data
    > the first place I
    > would look is the poorly secured desktops of the CEO and CFO.
    > Since many
    > organization appear to be IDS blind on client segments, Id
    > probably fly under
    > the radar as well.
    > The model can be easily supplemented with port and protocol
    > restrictions to
    > further protect the servers from the clients.
    > The model is very easily scalable, the example is for
    > demonstration purposes.
    > Research suggests the addition of: a tightly protected
    > master server segment,
    > for servers that query clients (server -> client protocols,
    > security scanners,
    > dhcp, backup servers?); a resources segment for things only
    > used by the
    > servers, like printers; the Internet (duh!); and something
    > intuitive keeps
    > wanting to separate out authorization servers (Domain
    > Controllers) as well.
    > Draw circles on the white board for each segment with arrows
    > to model the
    > firewall, any arrows that point at the clients have the
    > potential to infect the
    > entire organization, youve been warned.
    > With good IP space management, the model should scale across a WAN.
    > Questions? (aka, what have I missed?)
    > Chris
    > _______________________________________________
    > firewall-wizards mailing list

    firewall-wizards mailing list

  • Next message: Dave Piscitello: "Re: [fw-wiz] Re: Spyware mumbo jumbo and bigger woes"