On Tue, Aug 25, 2009 at 12:06 PM, Bill Moran <[email protected]>wrote:
> In response to Adam Vande More <[email protected]>: > > > On Tue, Aug 25, 2009 at 11:05 AM, Bill Moran <[email protected] > >wrote: > > > > > In response to Paul Schmehl <[email protected]>: > > > > > > > --On Tuesday, August 25, 2009 08:30:17 -0500 Colin Brace <[email protected]> > > > 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). > > > > > > 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 > > _______________________________________________ > > [email protected] mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > > To unsubscribe, send any mail to " > [email protected]" > > > -- > Bill Moran > http://www.potentialtech.com > http://people.collaborativefusion.com/~wmoran/<http://people.collaborativefusion.com/%7Ewmoran/> > -- Adam Vande More _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[email protected]"
