OUTPUT filtering (was: Re: Ip_conntrack_ftp ...)

[/dev/rob0 <rob0@gmx.co.uk>]

Jan Engelhardt wrote:
>>Hmm, many people, including myself, think, that filtering in OUTPUT is
>>pointless. More troublesome than usefull. If you decide to set OUTPUT
>>policy to ACCEPT, you don't need the first two rules. Up to you.
> 
> Not at all. Because certains things can not happen in certain environments, 
> e.g. I read/write mail by logging into a mail server via SSH / no sendmail 
> running, I can exclude certain things. In netfilter parlance:
> 
>  -P OUTPUT ACCEPT (same for FORWARD, btw)
>  -A OUTPUT -j REJECT -p tcp --dport 25
> 
> This stops users that also have access to my machine to not spam smtp servers, 
> should they find an open one.

(Be sure you also restrict access to any sendmail(1)-style mail 
injection binary in that case, if there's an MTA running.)

True, you have illustrated one example of sane OUTPUT filtering. The 
OP's use of OUTPUT filtering was not in this category.

Note that OUTPUT filtering only controls non-root users. A root user can 
disable or bypass it. If you have local shell users who cannot be 
trusted, and if you didn't already understand all this, chances are 
those users already have rooted you. :)

I agree with Joerg above. I don't think you have contradicted his 
general point. Netfilters should:
   1. Learn to walk before they try to run
      Rule of thumb: if you need to post here to try to get explanations
      of what your rules are doing, you're not ready for OUTPUT filters.
   2. Only experiment with carefully-crafted OUTPUT rules
   3. Generally not attempt "iptables -P OUTPUT DROP" (see #1.)
-- 
     mail to this address is discarded unless "/dev/rob0"
     or "not-spam" is in Subject: header