From owner-freebsd-questions@FreeBSD.ORG Tue Aug 25 17:06:19 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 970E1106568F for ; Tue, 25 Aug 2009 17:06:19 +0000 (UTC) (envelope-from wmoran@potentialtech.com) Received: from mail.potentialtech.com (internet.potentialtech.com [66.167.251.6]) by mx1.freebsd.org (Postfix) with ESMTP id 5B6718FC0C for ; Tue, 25 Aug 2009 17:06:19 +0000 (UTC) Received: from localhost (pr40.pitbpa0.pub.collaborativefusion.com [206.210.89.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.potentialtech.com (Postfix) with ESMTPSA id 60347EBC0A; Tue, 25 Aug 2009 13:06:18 -0400 (EDT) Date: Tue, 25 Aug 2009 13:06:16 -0400 From: Bill Moran To: Adam Vande More Message-Id: <20090825130616.20ab0049.wmoran@potentialtech.com> In-Reply-To: <6201873e0908250921w46000c2by78893a1c5b581e78@mail.gmail.com> References: <4A924601.3000507@lim.nl> <25130058.post@talk.nabble.com> <20090825091937.GA53416@cheddar.urgle.com> <25131646.post@talk.nabble.com> <200908251027.n7PARZBt009994@banyan.cs.ait.ac.th> <25132123.post@talk.nabble.com> <20090825082604.41cad357.wmoran@potentialtech.com> <25134277.post@talk.nabble.com> <20090825120504.93a7c51d.wmoran@potentialtech.com> <6201873e0908250921w46000c2by78893a1c5b581e78@mail.gmail.com> Organization: Bill Moran X-Mailer: Sylpheed 2.7.1 (GTK+ 2.16.5; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Paul Schmehl , freebsd-questions@freebsd.org, Colin Brace Subject: Re: what www perl script is running? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 17:06:19 -0000 In response to Adam Vande More : > On Tue, Aug 25, 2009 at 11:05 AM, Bill Moran wrote: > > > In response to Paul Schmehl : > > > > > --On Tuesday, August 25, 2009 08:30:17 -0500 Colin Brace > > wrote: > > > > > > > Bill Moran wrote: > > > >> > > > >> You can add an ipfw rule to prevent the script from calling home, > > which > > > >> will effectively render it neutered until you can track down and > > actually > > > >> _fix_ the problem. > > > > > > > > Mike Bristow above wrote: "The script is talking to 94.102.51.57 on > > port > > > > 7000". OK, so I how do I know what port the script is using for > > outgoing > > > > traffic on MY box? 7000 is the remote host port, right? > > > > > > > > FWIW, here are my core PF lines: > > > > > > > > pass out quick on $ext_if proto 41 > > > > pass out quick on gif0 inet6 > > > > pass in quick on gif0 inet6 proto icmp6 > > > > block in log > > > > > > > > That is to say: nothing is allowed in unless explicitly allowed > > > > Everything allowed out. > > > > (plus some ipv6 stuff I was testing with a tunnel) > > > > > > > > > > The problem with blocking outbound ports is that it breaks things in odd > > ways. > > > For example, your mail server listens on port 25 (and possibly 465 as > > well) but > > > it communicates with connecting clients on whatever ethereal port the > > client > > > decided to use. If the port the client selects happens to be in a range > > that > > > you are blocking, communication will be impossible and the client will > > report > > > that your mail server is non-responsive. > > > > You're doing it wrong. Block on the destination port _only_ and you don't > > care about the ephemeral ports. > > What ports would you block then when you're trying to run a webserver? My point (which is presented in examples below) is that you block everything and only allow what is needed (usually only dns and ntp, possibly smtp if the web server needs to send mail) That single statement above was directed specifically at the comment about it being impossible to predict (and thus block) ephemeral source ports. He's right about that, and that's why filtering on the destination port is the more common practice. Of course, that caused me to create an email that seems to contradict itself, if you don't notice that it's two answers to two different comments. > > > It's much easier to block outgoing ports for services you *don't* want to > > > offer, but, if the service isn't running anyway, blocking the port is > > > non-productive. > > > > You're obviously misunderstanding me completely. Your not blocking > > incoming > > connections, your preventing outgoing ones, which means there _is_ no > > service running on your local machine. > > > > For example, a server that is _only_ web (with SSH for admin) could have > > a ruleset like: > > > > pass in quick on $ext_if proto tcp from any to me port {25,587,465,22} keep > > state > > pass out quick on $ext_if proto tcp from me to any port {25} keep state > > pass out quick on $ext_if proto upd from me to any port {53,123} keep state > > block all > > > > (note that's only an example, there may be some fine points I'm missing) > > > > One thing that had not yet been mentioned when I posted my earlier comment, > > is that this system is a combination firewall/web server. That makes the > > rules more complicated, but the setup is still possible: > > > > pass in quick on $ext_if proto tcp from any to me port {80} keep state > > pass out quick on $ext_if proto upd from me to any port {53,123} keep state > > pass out quick on $ext_if from $internal_network to any all keep state > > block all > > > > Which allows limited outgoing traffic originating from the box itself, > > but allows unlimited outgoing traffic from systems on $internal_network. > > > > I've done this with great success. In fact, I had a fun time where a > > client in question was infected with viruses out the wazoo, but the > > viruses never spread off their local network because I only allowed > > SMTP traffic to their SMTP relay, which required SMTP auth (thus the > > viruses couldn't send mail) > > > > > > > -- > Adam Vande More > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/