> > Your statements are beyond ridiculous.  You are saying "If you need
> > to filter it, you should not be running it".
> 
> X doesn't have to listen on TCP 6000, you can setup a unix socket, and
> it's no longer reachable from the network, and you still have full
> functionality (I know, I do just that).

And I don't have the TIME OF DAY to do that, it is EASIER to filter!

AND IT USES LESS PROCESSOR!

AND IT USES LESS MEMORY!

> There's more than one way to
> do anything. If something needs to only be locally accessable, only
> have it listen locally, or use unix sockets instead of tcp/udp sockets
> completely.

No, that is not what you said:  You did not say "there are many ways
to do this".

Instead, you very specifically suggested that people NOT filter using
the packet filter, but to instead configure applications, or to NOT
run the servers in those locations then.

And THAT is what is utterly ridiculous.

It is plain simple bad advice.  And totally ridiculous.

You're wrong.  People should run packet filters wherever they want,
since in many cases it is EASIER than thousands of lines of later
code running and having a pre-authentication bug.

Telling people to go tune their applications, tune tune tune tune,
that is the mantra of Linux people who then run out of time and
expertise, and then leave their machines open.

People will NOT avoid running kde which opens half a thousand stupid
ports, and they will NOT go and learn to configure those applications
with a thousand buttons, because they don't have the TIME OF DAY to
follow your ridiculous "push more buttons you don't know" advice.

You're wrong.  Everyone -- run pf wherever you find it easier.

Reply via email to