On Tuesday 21 September 2004 11:57, Tom Allison wrote: > [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.
Query how? Based on what rules it an outgoing connection allowed/disallowed? > > > > 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. Using 'policy drop' for outgoing traffic, and then explicitly allowing certain traffic would do what you want, if I understand your question correctly. Try using something like firehol (firehol.sf.net), where it's really easy and convinient to define rules. > > (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. [ snip ] Why not just use connection tracking? Load the ip_conntrack_ftp module and create proper iptables rules. Iptables will then be able to recognize the high-port connection as RELATED to the original connection to port 21. B/R, -- Frederik Dannemare | mailto:[EMAIL PROTECTED] http://qa.debian.org/developer.php?login=Frederik+Dannemare http://frederik.dannemare.net | http://www.linuxworlddomination.dk Key fingerprint: BB7B 078A 0DBF 7663 180A F84A 2D25 FAD5 9C4E B5A8 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]