Re: Re: Code Red: What security specialist don't mention in warnings(Frank Knobbe)

["daN." <dan () evilhippo com>]

I don't think you see what I'm saying..malicious worm/virii/whatever gets 
on the inside of your network and wants to open a tunnel to the outside 
world to accept instructions:
malicious client looks up WHAT_DO_YOU_WANT_ME_TO_DO.Malicious.dns.com
this could be a TEXT or MX query that allows for text to be sent back, the 
originating client, your query gets passed along to the DMZ DNS, which 
takes it and sends it off to Malicious.dns.com which responds with a 
perfectly legal DNS reply which is in fact a code telling what it want the 
internal client..if it wants the client to pass back a file the client can 
just make a whole lot of DNS requests in the form of 
SEQUENCE_NUMBER.ENCODED_FILE_CHUNK.Malicious.dns.com.
Basically what I am saying is you can tunnel ANYTHING legally over ANY 
protocol, and as long as the initial attack if legal from a protocol 
standpoint, or not checked for there is nothing whale gap or any other 
firewall for that matter can do about it.

daN.

At 10:15 AM 8/13/01 -0400, B. Scott Harroff wrote:
> Regarding not being able to block malicious DNS, I disagree.  Suppose:
>
> For Internet DNS (client) resolution:  Configure your internal users to use
> a DNS server(s) in a DMZ setting.  Configure your DNS server(s) as
> forwarder/slave(s) to the IP address(s) of your ISP's DNS servers (or your
> favorite trusted Internet DNS server).   Permit only inbound DNS queries
> w/SYN set (and the stateful response) from your internal networks to your
> DMZ DNS server.   Permit only outbound queries w/SYN set (and the stateful
> responce) from your DNS server to the trusted IP addresses of the outside
> DNS servers you selected.  Permit only the necessary ICMP requests/responces
> from these servers.
>
> For DNS hosting, allow your ISP to be secondary, and your server to be
> primary (so you can change/manage your DNS). Again, impliment your DNS
> server(s) in a DMZ and allow only inbound/outbound DNS w/SYN set (and the
> stateful responce) from the trusted IP address(s) of your ISP (secondary)
> DNS server(s) to your DNS server(s) (primary). Permit only the necessary
> ICMP requests/responces from these servers.
>
> ----- Original Message -----
> From: "daN." <dan () evilhippo com>
> To: "Joseph Steinberg" <Joseph () whale-com com>; "Bob Washburne"
> <rcwash () concentric net>; <firewall-wizards () nfr com>
> Sent: Friday, August 10, 2001 2:37 AM
> Subject: Re: [fw-wiz] Re: Code Red: What security specialist don't mention
> in warnings(Frank Knobbe)
>
>
> > Sigh...Even an application proxy cannot stop a cleverly designed trojan
> > from tunneling out..what if it uses valid DNS queries as the tunnel? You
> > can, block them and the relay them along, and then relay back an encoded
> > DNS reply..there is absolutely no way of stopping this, and you can do
> > similar over any valid services, application proxies can only take things
> > so far..and there are many many many servers which crash upon receiving
> > messages completely legal by the protocol.
> >
> > daN.
> >
> > At 11:49 AM 8/6/01 -0400, Joseph Steinberg wrote:
> >
> > >I agree wholeheartedly that we do need to come up with a better way of
> > >addressing these issues than patching every specific vulnerability. Our
> > >e-Gap systems do this with positive logic -- i.e., enforcing that
> > >web-servers/applications only receive requests in formats that the
> > >web-servers/apps expect. So, worm attacks, hacker attacks, etc. (which
> are
> > >generally based on unexpected submissions) fail -- regardless of whether
> the
> > >particular hack is known to our product or not. I am curious how others
> deal
> > >with this.
> > >
> > >Tunneling -> There are ways to mitigate against tunneling threats. I know
> > >that our products address tunneling by eliminating TCP/IP connectivity
> and
> > >TCP/IP headers, there may be other that do so as well. We also
> distinguish
> > >between types of attacks, and I am certain others do as well.
> > >
> > >BTW: Even a firewall with a strong application proxy will likely not
> solve
> > >this unless it uses positive logic. There will always be new
> vulnerabilities
> > >to keep up with.
> > >
> > >Joseph
> > >
> > > >Security is not a binary value, yes or no, but a spectrum.  The more
> > > >secure you make the system the fewer worms and script kiddies get
> > > >through.  In this case, Code Red would have been contained (and
> probably
> > > >was on many well maintained systems).  Are there still holes?  Sure.
> > >
> > > >There is no protection at this moment from tunneling.
> > >
> > > >Also, a well formed DDOS attack is indestinguishable from the "Slashdot
> > > >Effect."  So there is no defence from that one.
> > >
> > > >But that doesn't mean that we just give up, go home and play with our
> > > >Commodore 64's.
> > >
> > > >So I must agree that patching is not the only issue here.  I cannot
> > > >clean up the web, but I appreciate the helpfull ideas to help protect
> my
> > > >site.
> > >_______________________________________________
> > >firewall-wizards mailing list
> > >firewall-wizards () nfr com
> > >http://list.nfr.com/mailman/listinfo/firewall-wizards
> >
> > _______________________________________________
> > firewall-wizards mailing list
> > firewall-wizards () nfr com
> > http://list.nfr.com/mailman/listinfo/firewall-wizards

_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://list.nfr.com/mailman/listinfo/firewall-wizards