Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 25 Aug 2009 11:21:16 -0500
From:      Adam Vande More <amvandemore@gmail.com>
To:        Bill Moran <wmoran@potentialtech.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:  <6201873e0908250921w46000c2by78893a1c5b581e78@mail.gmail.com>
In-Reply-To: <20090825120504.93a7c51d.wmoran@potentialtech.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> <E668BECE594402B585544841@utd65257.utdallas.edu> <20090825120504.93a7c51d.wmoran@potentialtech.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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?

>
>
> > 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6201873e0908250921w46000c2by78893a1c5b581e78>