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

["Tony" <fwWiz-post-9831a () tony3 com>]

Hi Scott,

  I think that you misunderstood daN.  Suppose an attacker has taken over
one of your internal servers.  All lookups below are done by the
compromised machine:

----
Lookup "i-own-192-168-2-2.int-nat-gw-12-4-2-1.attacker.org"
Response "19.2.33.1"
----

Now, the attacker knows that they have control of 192.168.2.2 with NAT
gateway 12.4.2.1.  Suppose that the remote access trojan is programmed to
do a reverse lookup for the returned address.

----
Lookup PTR for 19.2.33.1
Response "attack-192-168-2-1.attacker.org"
----

The trojan has received the command to attack 192.168.2.1.  The only
limitation to this type of communication is that its initiation is half
duplex.  The attacker cannot send a command to the trojaned machine until
the trojaned machine initiates a DNS query.  Lack of a reverse channel
simply requires the trojan to poll the attacker for new commands
automatically.

These requests and responses are completely valid and will be forwarded
by any intermediary DNS servers that you place in the resolution path.
How do you prevent against this type of tunneling?  You can't without
affecting functionality of the underlying service.

 - Tony


-----Original Message-----
From: firewall-wizards-admin () nfr com
[mailto:firewall-wizards-admin () nfr com]On Behalf Of B. Scott Harroff
Sent: Monday, August 13, 2001 9:16 AM
To: Joseph Steinberg; Bob Washburne; firewall-wizards () nfr com; daN.
Subject: Re: [fw-wiz] Re: Code Red: What security specialist don't
mention in warnings(Frank Knobbe)


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

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