On Wed, Aug 26, 2009 at 8:30 AM, Bill Moran <wmo...@potentialtech.com>wrote:

> In response to Adam Vande More <amvandem...@gmail.com>:
>
> > On Wed, Aug 26, 2009 at 7:11 AM, Bill Moran <wmo...@potentialtech.com
> >wrote:
> >
> > > Adam Vande More <amvandem...@gmail.com> wrote:
> > > >
> > > > On Tue, Aug 25, 2009 at 2:43 PM, Bill Moran <
> wmo...@potentialtech.com
> > > >wrote:
> > > >
> > > > > In response to Adam Vande More <amvandem...@gmail.com>:
> > > > >
> > > > > > On Tue, Aug 25, 2009 at 12:06 PM, Bill Moran <
> > > wmo...@potentialtech.com
> > > > > >wrote:
> > > > > >
> > > > > > > In response to Adam Vande More <amvandem...@gmail.com>:
> > > > > > >
> > > > > > > > On Tue, Aug 25, 2009 at 11:05 AM, Bill Moran <
> > > > > wmo...@potentialtech.com
> > > > > > > >wrote:
> > > > > > > >
> > > > > > > > > In response to Paul Schmehl <pschmehl_li...@tx.rr.com>:
> > > > > > > > >
> > > > > > > > > > --On Tuesday, August 25, 2009 08:30:17 -0500 Colin Brace
> <
> > > > > c...@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-unsubscr...@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/>
> > > > > <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
>
> Why not?  Because you said so?
>
> > 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.
>
> This paragraph serves to further convince me that you are getting
> concepts confused.  I see no reason for me to continue discussing this.
>
> Specifically what am I confused on?  Or are you just going to continue with
the personal attacks?  You've offered no technical rebuttal, simply insults.


-- 
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-unsubscr...@freebsd.org"

Reply via email to