what www perl script is running?

Wed Aug 26 13:20:56 UTC 2009

On Wed, Aug 26, 2009 at 7:11 AM, Bill Moran <wmoran at potentialtech.com>wrote:

> Adam Vande More <amvandemore at gmail.com> wrote:
> >
> > On Tue, Aug 25, 2009 at 2:43 PM, Bill Moran <wmoran at potentialtech.com
> >wrote:
> >
> > > In response to Adam Vande More <amvandemore at gmail.com>:
> > >
> > > > On Tue, Aug 25, 2009 at 12:06 PM, Bill Moran <
> wmoran at potentialtech.com
> > > >wrote:
> > > >
> > > > > In response to Adam Vande More <amvandemore at gmail.com>:
> > > > >
> > > > > > On Tue, Aug 25, 2009 at 11:05 AM, Bill Moran <
> > > wmoran at potentialtech.com
> > > > > >wrote:
> > > > > >
> > > > > > > In response to Paul Schmehl <pschmehl_lists at tx.rr.com>:
> > > > > > >
> > > > > > > > --On Tuesday, August 25, 2009 08:30:17 -0500 Colin Brace <
> > > cb at 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 at freebsd.org mailing list
> > > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> > > > > > To unsubscribe, send any mail to "
> > > > > freebsd-questions-unsubscribe at freebsd.org"
> > > > >
> > > > >
> > > > > --
> > > > > Bill Moran
> > > > > http://www.potentialtech.com
> > > > > http://people.collaborativefusion.com/~wmoran/<http://people.collaborativefusion.com/%7Ewmoran/>
> <http://people.collaborativefusion.com/%7Ewmoran/>
> > > <http://people.collaborativefusion.com/%7Ewmoran/>
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Adam Vande More
> > >
> > You said block by destination port.  What you presented is not this,
> > although it gives give a functional environment of it.  Sorry for the
> > pedantic pursuit here, but IMO terminology is important here.
>
> Both of my examples are filtering based on destination port.  In reviewing
> this thread, you make the statement "destination ports are ephemeral" which
> is wrong.  I can only assume that your understanding of IP port usage is
> wrong or incomplete.
>

blocking destination port != keep state

and destination port are certainly ephemeral simply depends on pov.  Your
original statement indicated blocking by port at egress was the way to go.
Your example did no such thing, it tracked state which is completely
different from both a functional and technical standpoint.

-- 
Adam Vande More