Date: Tue, 25 Aug 2009 15:43:58 -0400 From: Bill Moran <wmoran@potentialtech.com> To: Adam Vande More <amvandemore@gmail.com> Cc: Paul Schmehl <pschmehl_lists@tx.rr.com>, freebsd-questions@freebsd.org, Colin Brace <cb@lim.nl> Subject: Re: what www perl script is running? Message-ID: <20090825154358.7c792d3a.wmoran@potentialtech.com> In-Reply-To: <6201873e0908251237n5c819d9ag36f867b5e68e258c@mail.gmail.com> References: <4A924601.3000507@lim.nl> <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> <E668BECE594402B585544841@utd65257.utdallas.edu> <20090825120504.93a7c51d.wmoran@potentialtech.com> <6201873e0908250921w46000c2by78893a1c5b581e78@mail.gmail.com> <20090825130616.20ab0049.wmoran@potentialtech.com> <6201873e0908251237n5c819d9ag36f867b5e68e258c@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In response to Adam Vande More <amvandemore@gmail.com>:
> On Tue, Aug 25, 2009 at 12:06 PM, Bill Moran <wmoran@potentialtech.com>wrote:
>
> > In response to Adam Vande More <amvandemore@gmail.com>:
> >
> > > On Tue, Aug 25, 2009 at 11:05 AM, Bill Moran <wmoran@potentialtech.com
> > >wrote:
> > >
> > > > In response to Paul Schmehl <pschmehl_lists@tx.rr.com>:
> > > >
> > > > > --On Tuesday, August 25, 2009 08:30:17 -0500 Colin Brace <cb@lim.nl>
> > > > 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.
>
> My point was that it's unfeasible to block by destination point. You can
> only block by destination port if it's a known quantity, and the destination
> port is ephemeral in the question I posed(which what the OP had an issue
> with).
Please read the entire email before you respond. My last example below
demonstrates how to do what you call "unfeasible".
> > > > > 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/<http://people.collaborativefusion.com/%7Ewmoran/>;
> >
>
>
>
> --
> Adam Vande More
--
Bill Moran
http://www.potentialtech.com
http://people.collaborativefusion.com/~wmoran/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090825154358.7c792d3a.wmoran>