what www perl script is running?

Bill Moran wmoran at potentialtech.com
Tue Aug 25 17:06:19 UTC 2009


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.

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


More information about the freebsd-questions mailing list