Is Firwall necessay? - Firewalls

This is a discussion on Is Firwall necessay? - Firewalls ; Greg Hennessy wrote: >>>>BSD+ipfw/pf or Linux+netfilter would be the best choice, for obvious >>>>reasons. >>> >>> Don't teach your grandmother how to suck eggs. >>> >>> Show me a 'free' solution which can dynamically filter soap/xml/rpc *and* >>> doesn't require ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 23 of 23

Thread: Is Firwall necessay?

  1. Re: Is Firwall necessay?

    Greg Hennessy wrote:

    >>>>BSD+ipfw/pf or Linux+netfilter would be the best choice, for obvious
    >>>>reasons.
    >>>
    >>> Don't teach your grandmother how to suck eggs.
    >>>
    >>> Show me a 'free' solution which can dynamically filter soap/xml/rpc *and*
    >>> doesn't require command line hackery to manage.

    >>
    >>This "command line hackery" as you call it is exactly why you can utilize a
    >>wide variety of management tools, including graphical ones.

    >
    > You haven't answered the question.
    >
    > Show me the free out of the box pf/ipfw/netfilter solution which can filter
    > soap, xml & rpc.


    ShoreWall. Redhat Enterprise Firewall Server. All the flavors are belong to
    you.

    > Pointing to an unsupportable netfilter hack someone has
    > posted on sourceforge doesnt cut the mustard in an enterprise environment.


    Put an IBM sticker on it. The management will be satisfied.

    >> Just show me
    >>one "non-free" solution that could compare to the management of large
    >>networks with ShoreWall.

    >
    > BWAHAHAHA! Oh Jesus wept... Shorewall .... Look do yourself a favour, I'll
    > give you some hints Cisco Security Manager, Checkpoint Provider-1,
    > Netscreen Security Manager just to name 3.


    Ugly, ugly≤ and ugly≥.

    > Your lack of knowledge on the topic is just too embarrasing for words.


    Then save those for yourself. Might be a wise consideration.

    >>> Show me the netfilter/pf solution that can dynamically fixup and sanitise a
    >>> huge range of application protocols other than basic FTP.

    >>
    >>Well, netfilter. I just looked at the list... weeh, more than 900 helper
    >>modules for netfilter.

    >
    > You dont comprehend the change management constraints which enterprises
    > operate under.
    >
    > The notion that risk management in any large organsiation would even
    > contemplate permitting the roll of out netfilter 'helper' modules across a
    > global network to selectively filter SOAP & RPC is hilarious.
    >
    > Never mind rolling out hacks which run application layer filtering in
    > kernel space.


    I wonder where you want to draw the line to the even dirtier solutions
    you're talking about.

    >> Including one for such nasty stuff like H.323 which
    >>you can find no-where else.

    >
    > Oh gawd. Open your eyes puhleeze. Crisco, Checkpoint and Netscreen can and
    > do fixup 323 and other voip protocols.


    I was talking about working protocol parsers, not just some half-working
    cheap hacks.

    >>> Again you have demonstrated a lack of real world experience, client
    >>> requirements extend far beyond mere L3 packet filtering.

    >>
    >>I never claimed anything in this way.

    >
    > Of course you did, you insisted


    Nonsense. Where?

    > "BSD+ipfw/pf or Linux+netfilter would be the best choice, for obvious
    > reasons."
    >
    > without having any idea of what the client requirements were.


    The most important requirement of a firewall is to provide security on a
    network boundary. And with security comes avoiding complexity.

    >>But well, as you may understand, most
    >>L7 protocol filtering is done using proxy firewalls.

    >
    > Again you make authoritiative claims without having a clue of the real
    > world capabilities of the products in the market place. In the real world,
    > there are 3 main players, Crisco, Juniper and & Checkpoint. They all
    > provide L7 filtering in various forms.
    >
    > The notion that
    >
    > "*most* L7 protocol filtering is done using proxy firewalls"
    >
    > is arrant nonsense.


    Sorry for specifying "sane approach of".

    >>sizeof(Windows_installation_stripped_down) = 300 MB+
    >>sizeof(Linux_from_a_scratch+netfilter) = 1 MB
    >>
    >>I rest my case.

    >
    > ridiculously irrelevant. Show me a 1 meg LFS floppy disk with support for
    > say OSPF, BGP, sparse PIM which can dynamically route several hundred
    > market data feeds delivered though trunks running into a Cat 6509.


    Then 2 MB, mainly for the sparse PIM. (WTF? Does this belong to a
    firewall?). Kernel is 0.5 MB, OSPF and BGB support are 200 KB and the
    thrunk's interface driver is 100 KB. I'd say this fits well.

    >> You really don't understand how much overkill and
    >>complexity a Windows installation provides, and how hard it is to properly
    >>secure it just on its own.

    >
    > By that reasoning the same fallacious 'point' would apply to Splat Pro or
    > Solaris.


    Agreed for Solaris, this is really a monster as well. Even though not a
    monstruos as Windows.

    > Windows Server is *not* hard to secure. Whether you choose to believe that
    > is not my problem.


    Well, see above. It seems like you really like underestimating complexity.

    > You dont, it's painfully obvious that your exposure to anything other than
    > soho solutions to security infrastructure delivery is extremely limited.


    .... says someone who doesn't even know the extensive variety of management
    solutions for Unix systems which are mostly based upon pf, ipfw or
    netfilter in the core.

  2. Re: Is Firwall necessay?

    Will wrote:

    > In any case, it's a lot more secure to isolate the application in a virtual
    > machine than to run it in the same application space as the firewall.


    And a lot more unusable. Ever tried copy & paste? What about opening files?
    Programs are doing IPC for good reason. And once you begin to share data
    between the VMs, you're likely to copy the compromised data and infect
    another VM (or even the host).

    > So if you have unlimited money, go with Approach 3. But Approach 2 is at
    > least decent protection, particularly given the cost savings.. Approach 1
    > is a complete joke.


    What about Approach #4: Do not get the malware executed in first place?


    > My point being that I want protection from kiddy hackers.


    The don't run the malware.

    > It takes a very
    > sophisticated intruder to try to tunnel back into your network during the 5
    > to10 second windows of opportunity that are opened during the return packet
    > state from an outgoing UDP request.


    No. It's simply program code, readily available from the internet and
    already integrated in the most favorite trojan horses.

    >> 3a. If you're providing NAT throught the VM monitor, the firewall can't
    >> work since it doesn't know about the NAT states, or can't provide any
    >> security because you have to emulate that behaviour in an obviously
    >> insecure manner.
    >> 3b. If you're providing NAT through the firewall, then the VMs won't get
    >> any connection.
    >> 3c. If you're providing NAT through both mechanisms, you still have the
    >> problem of the tow mechanisms not knowing the states of each other, so
    >> you'll either get it insecure or non-working.

    >
    > Excellent and true, which is why you never use the NAT adapter.... You
    > create virtual *private* networks, and connect those to a routing firewall
    > that runs on the host computer.


    That's where #3b or #3c applies.

    >> Question: What should the routing firewall do?
    >> a) forward to the virtual interface of VM A
    >> b) forward to the program running on the physical host
    >> c) drop the packet
    >>
    >> Hint: Neither is right. From a security perspective, one would choose C,
    >> but then you'd have ****ed up the network. If you don't choose C, you're
    >> trivially getting insecure.
    >>
    >> I guess you be able to construct a similar scenario for the case of port
    >> forwarding being utilized.

    >
    > If the return ACK from the original TCP SYN doesn't reach the host firewall
    > within the timeout, then the packet is dropped. Why would it be otherwise?


    You already forwarded the SYN/ACK to the wrong interface. That's already
    bad.

    Oh, not to mention UDP, which is somehow connection-less.

    > The virtual machine does not "see" the physical interface. The virtual
    > machines don't share it. The host has exclusive view and use of the
    > external interface, just like in any real firewall.


    No. The host uses the physical interface for his own purposes, as well as
    providing network connectivity to the VMs.

  3. Re: Is Firwall necessay?

    On Mon, 29 Jan 2007 21:51:36 +0100, Sebastian Gottschalk
    wrote:


    >> You haven't answered the question.
    >>
    >> Show me the free out of the box pf/ipfw/netfilter solution which can filter
    >> soap, xml & rpc.

    >
    >ShoreWall. Redhat Enterprise Firewall Server. All the flavors are belong to


    >you.



    Oh for crying out loud, not this nonsense again.

    RHES is *not* free.

    Netfilter on RHES does *not* filter soap/xml or rpc. Blocking ports at
    layer 3 is does not constitute meaningful filtering, especially when soap
    is delivered over 80/tcp.

    If you actually had any experience of the subject matter, it would be
    painfully obvious that I am referring to filtering RMI , schema checking &
    tracking UUID endpoint maps.

    The fact that you appear to be unable to conceive of a use for multicast
    routing on an edge security device is further proof that your level of real
    world exposure to network security design & implementation is limited to
    say the least.




    greg

    --
    "He's raising an unholy army of singing dinosaurs!"

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2