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

["B. Scott Harroff" <Scott.Harroff () att net>]

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