On Thursday, December 19, 1996 10:28 PM, Stout,
Bill[SMTP:bill .
stout @
hidata .
com] wrote:
>Java, javascript, Active-X and downloadable .exe's/.zip's
>are becoming more commonplace. (Didn't you send someone a
>Christmas cards .exe in e-mail?)
>
>Programs are beginning to adapt to firewalls passing only
>standard port traffic out such as 23, 25, 119, 80, 443.
>Maybe also (future) 135.
>
>What prevents a program from connecting back out and
>creating a tunnel to a hackers portal system? What
>prevents such a program from polling for instructions
>from such a site, instead of a hacker actually having
>enter into a firewalled site?
>
>Boomerang! Instead of hackers coming in from the outside,
>their agent programs get instructions from a master site,
>and from the inside, out.
This is a classic Trojan Horse attack except that instead of being given
explicit instructions before being sent to the victim site, the trojan is
in remote-control mode through the FW.
Trojans have always been a problem since the beginning of time (on my
computer it's Jan-01-80...) and the traditional way of preventing damage is
strict
adherence and enforcement of a security policy which transcends
internetworking security and addresses computer policy (ie. what is safe to
download and execute on your computer?) Some companies expressly forbid any
foreign binaries to be introduced to their mission-critical systems, even
(especially?) by floppy. Why should Internet-originated executable code be
any different? Again, this is a job for a different layer of your security
policy, one which firewalls may not be able to enforce.
Having said this, I would imagine then the only way to protect against the
remote-control-type trojans with a firewall would be to use
application-level gateways which monitor all application-specific traffic.
For example, if I successfully push a trojan through a firewall and then
have it communicate to my master site via port 80, the http
application-level gateway would immediately raise alarms if it did not
recognize any of the protocol-specific traffic being passed through. Any
directives not matching "GET", "PUT", etc. would be denied (hopefully).
Note that data theft via http and ftp-compliant protocol traffic would
still be a threat, but at least the attacker will not have the equivalent
of a telnet session into your host.
Your remote-control trojan would have the most effectiveness through a
packet-filtering-only firewall, which I guess is yet another argument
against such FWs and filtering routers.
--
Gene Lee
genel @
inforamp .
net
genelee @
vnet .
ibm .
com
Follow-Ups:
|
|
