Re: All these open ports
On Tuesday 21 September 2004 11:57, Tom Allison wrote:
> email@example.com 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
> > 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
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.
Frederik Dannemare | mailto:firstname.lastname@example.org
http://frederik.dannemare.net | http://www.linuxworlddomination.dk
Key fingerprint: BB7B 078A 0DBF 7663 180A F84A 2D25 FAD5 9C4E B5A8