what www perl script is running?

[Bill Moran]

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

-- 
Bill Moran
http://www.potentialtech.com