[EMAIL PROTECTED] wrote:
If a port is open, and associated with a program which isn't from a
debian package and you don't believe you put it there yourself - its
time to consider the possibility your machine has been compromised.


Okay...  that gives me an opening to try this again.

At the risk of provoking the usual "WELL GO RUN WINDOWS THEN!!!"
knee-jerk reaction, I will mention that the Gatesware-based firewall
packages (like "Zone Alarm") will detect *outgoing* connection attempts
and query whether they are legitimate.

There has been some dicsuscion on the net w/r/t the fact that apparently
the later (per)versions of Gatesware have some "trojans" embedded in the
OS, which will connect to Billsoft to report your social security
number, sexual preference, etc. etc. - the point being that (allegedly)
the
commercial firewall products can't detect such attempts to "phone home".

In any case, I've as yet been unable to find any way of getting
detection and authorization of outgoing requests with any
of the Linux firewalls, or with IPtables - although I can hardly say
that
I've thoroughly done my homework - but I have asked here and there and
thus far no one seems to know.  The "Paradigm" seems to be that if
it's something that got spawned on your machine, and is trying to
connect
outward, it by definition must be legitimate, so it gets granted a port,
unless whatever port it is requesting is *already* explicitly blocked
by "iptables" or whatever for some reason.

(Okay, now, everybody yell in unison:  "WELL GO RUN WINDOWS THEN!!!")



There's several aspects of this that you have overlooked regarding just the basics of iptables and the state of TCP/IP today.


First, iptables can be configured such that filtered port traffic can be directed into userspace wherein you can do anything you would like to with them, including adding rules to permit their traffic.

The methods by which you could query outgoing traffic is numerous with or without iptables.

But more importantly you have to understand that you cannot block and query all traffic going out from your computer. If you did that, you would block FTP for the majority of environments. Namely, passive mode FTP which was popularized by Microsoft. Prior to this everyone had the notion of connection through the control and data ports which were traceable and identifiable.

Passive mode FTP allows you to make a high port connection to another high port connection. Both of these port numbers are not defined until the connection is attempted. This connection cannot be filtered in iptables because you have to create a high-port to high-port connection ACCEPT rule in order for passive mode to work. This iptables rule will allow anything to connect so you get into a lot of problems with being able to connect trojans or virus in the same manner.

More importantly today is to understand how 99.9% of the virus and malware is transmitted today. It's not through unfiltered ports and such as described in your original email, but through the email mechanism (or http) itself. And while I don't have any hard numbers at my desk to support the 99.9% claim, I don't believe it to be too far off the mark.

If you want to block a vast majority of the virus problems on the internet today then email should be configured to not execute anything when it receives a message and the MSIE browser should be fixed so that I cannot send an EXE file with a TEXT/HTML description, allowing your browser to download it as HTML and then the file explorer portion of the browser functionality to execute the EXE file based on name extension.

These are fundamental mistakes in software design that would never have been allowed if intelligent people where in charge. While I deeply loathe MSFT for more good reasons than I can publish in a day, I think these security problems are evidence of Marketing superceding the Engineering forces in the company, resulting in some really stupid things being done for some eye-candy reasons. Engineering isn't stupid, they're just asked to do some really stupid things.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Reply via email to